home *** CD-ROM | disk | FTP | other *** search
/ Gekikoh Dennoh Club 1 / Gekikoh Dennoh Club Vol. 1 (Japan).7z / Gekikoh Dennoh Club Vol. 1 (Japan) (Track 1).bin / kowin / archive / sys / kowin14d.lzh / doc / programming / memory.doc < prev    next >
Text File  |  1995-11-14  |  5KB  |  114 lines
  1.  
  2.  Ko-Window プログラマーズマニュアル
  3.  
  4. 「メモリ関連」 (難易度:高)
  5.  
  6.  
  7. ● Ko-Window でのメモリ確保
  8.  
  9.   Ko-Window で任意の領域のメモリを必要とした場合、動的に確保して使用できるの
  10. は以下の関数です。
  11.  
  12. ・malloc()/free()  ----- ノーマル版(XC-lib や libc 標準の malloc)
  13.  
  14.   普通にコンパイルした場合、XClib や libc での malloc() (calloc等も当然含む)
  15. はそれぞれのプロセスに最初に割り当てられた固定サイズの HEAP領域からメモリの
  16. 確保を行います。ウィンドウプログラム終了時に HEAP は勝手に開放されるため、もっ
  17. とも簡単でかつ高速です。細かな領域を頻繁に確保したり開放したりする必要がある
  18. 場合は、最初に任意の大きさの HEAP を確保したのちこの malloc() を使用して下さ
  19. い。
  20.  
  21.  
  22. ・malloc()/free()  ----- mm_alloc ライブラリ版 (v2.24+14 以降付属)
  23.  
  24.   実行時にあわせて消費するメモリ量が違ってくる場合、例えばテキストエディタ等
  25. は読み込むファイルの大きさによって必要とするメモリが極端に異なってしまいます。
  26. そういう場合は mm_alloc ライブラリ( mm_klib.a ) を使用して下さい。これを最初
  27. にリンクしておくだけで、ヒープ領域は自動拡張されるようになります。
  28.  
  29.  
  30.   <<WindowHeapSize の設定値の参照はいつか>>
  31.    HEAP 領域は最初の起動時に、グローバル変数 WindowHeapSize に初期値として書
  32.    き込んであるサイズ分だけ確保します。この変数の参照は起動時の１番最初だけ
  33.    なので、あとからプログラムで書き換えても意味がありません。つまりコンパイ
  34.    ル時の値のみ有効となります。
  35.  
  36.  
  37. ・MALLOC()/MFREE()
  38.  
  39.   これは直接 OS の管理するメモリブロックを確保するものです。DOS CALL です。
  40.  Ko-Window の管理から外れ、OS から確保を行うため使うにはかなりの注意が必要で
  41. す。もしどうしても使うのであれば、自分で確保した領域は必ず自分で責任を持って
  42. 開放して下さい。MFREE() せずにプログラムを終了すると、そのメモリブロックは存
  43. 在したまま残ります。(Ko-Windowを終了すれば一応開放される) このメモリの確保や
  44. 開放は極めて重く、細かい多数のメモリ確保には向きません。その代わり OS のメモ
  45. リの残り容量を最大まで使用可能であるため、起動時にはどれだけ消費するか不明な
  46. 巨大な単一のブロックを確保する場合に向いています。かなりプログラミングに慣れ
  47. たプログラマにしかお勧めできません。
  48.  
  49.  
  50.  
  51. ・WindowMemoryAlloc()/WindowMemoryFree()
  52.  
  53.   サーバーの HEAP 領域からメモリを確保します。サーバーの HEAP から確保する以
  54. 外はさほど取り立てて特徴はありません。MALLOC() 同様プログラムが終了しても残っ
  55. てしまうため、使い終わったメモリは自分で責任を持って開放して下さい。MALLOC()
  56. よりは細かなメモリ操作にも耐えます。
  57.  
  58.  
  59.  
  60. ● Ko-Window 起動時のメモリ確保の仕組み
  61.  
  62.   最初に1つのプロセスとして起動されたアプリケーションは、自分で持っていたHEAP
  63. や STACK を捨てて常駐します。その時アプリケーション用の HEAP 領域を別の OS の
  64. メモリブロックとして確保します。つまり通常の Human のプロセスとは違って、Ko
  65. のアプリケーションは、HEAP 領域を使う場合は OS のメモリブロックを 2 つ確保す
  66. ることになります。
  67.   Human では、実行プログラムには必ずその時存在する最大のメモリブロックが割り
  68. 当てられます。しかし MALLOC() による確保では、指定の容量が確保できる最初に見
  69. つかった空き領域から確保されます。
  70.  
  71.  
  72. １番最初のアプリケーションを起動する場合
  73.  
  74. (1) 起動前
  75. ──────┬───────────────────────────────
  76.  使用中     ｜空き(最大の空きブロック)
  77. ──────┴───────────────────────────────
  78. (2) アプリケーションのプロセスをロード
  79.   最初はプログラムが最大の空きブロックを全部確保
  80. ──────┬───────────────────────────────
  81.  使用中     ｜Aプログラム
  82. ──────┴───────────────────────────────
  83. (3) プログラム実行
  84.   プログラムが、自分で使う分だけを残して残りを開放
  85. ──────┬───────────┬───────────────────
  86.  使用中     ｜Aプログラム           ｜空き(最大の空きブロック)
  87. ──────┴───────────┴───────────────────
  88. (4) HEAP の確保
  89.   Koのアプリは、HEAP領域を別に確保する
  90. ──────┬───────────┬────┬──────────────
  91.  使用中     ｜Aプログラム           ｜AのHEAP ｜空き(最大の空きブロック)
  92. ──────┴───────────┴────┴──────────────
  93. (5) アプリケーションの常駐終了
  94.   アプリケーションを登録して終了、この時常駐に不要な部分はさらに切り落とす
  95. ──────┬──────┬────┬────┬──────────────
  96.  使用中     ｜Aプログラム ｜空き    ｜AのHEAP ｜空き(最大の空きブロック)
  97. ──────┴──────┴────┴────┴──────────────
  98.  
  99.   map.win 等でメモリブロックを見ていると、Ko-Window 起動時に最初に必ず不連続
  100. 部分ができるのはなぜか、と質問されることがあります。その理由は上記の通りです。
  101.  
  102.   この後さらに Ko のアプリを起動した場合は、最大の空きブロックにプログラムは
  103. ロードされるものの、HEAPは途中にある Aプログラム直後の空きに確保されることが
  104. あります。map.win を見ていると一見不可解な動きをしているように見えますが、実
  105. はこういうわけなのです。
  106.  
  107.  
  108.  
  109. 1995/2/17  小笠原博之
  110. oga@dgw.yz.yamagata-u.ac.jp
  111. DenDenNET: DEN0006 COR.
  112.  
  113. 1995/11/14 最終更新
  114.